home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Best of Shareware
/
Best of PC Windows Shareware 1.0 - Wayzata Technology (7111) (1993).iso
/
mac
/
DOS
/
TELECOMM
/
POINT165
/
FIDOINFO.TXT
< prev
next >
Wrap
Text File
|
1993-09-12
|
12KB
|
230 lines
The following text was written by Scott Dudley, author of
MAXIMUS, one of the most common BBS systems in use on the planet.
Scott has also written a mail processor called SQUISH which is
also a world leader in processing Fidonet mail. The following
was taken from the documentation file for Squish with the kind
permision of Mr. Dudley.
* * *
The following text is copyright 1991 by Scott J. Dudley. All
rights reserved.
NETWORK PRIMER
by, Scott Dudley
1:249/106
This section is intended as a primer for SysOps who are new to
FidoNet or a FidoNet Technology Network (FTN). This section
covers many of the terms and concepts which are required for
everyday FidoNet operations.
The Basics
The term "FidoNet" refers to an amateur electronic mail network,
run collectively by a group of system operators. In the
beginning, FidoNet started out as a simple system for exchanging
private messages between different bulletin boards. Since then,
FidoNet has grown into a full-fledged electronic mail and
conferencing network which has members in most countries of the
world.
FidoNet itself is organized into a numerical hierarchy of
"zones", "regions", "nets", "nodes" and "points". Each member of
FidoNet, individually known as a "node", can be uniquely
identified by that system's zone, net, node and point numbers.
To define each term:
Zones are wide geographical areas, usually covering one or more
continents. At the time of writing, FidoNet currently has six
zones: zone 1 (North America), zone 2 (Europe), zone 3
(Oceania), zone 4 (South America), zone 5 (Africa) and zone 6
(Asia).
Nets cover a much smaller area than zones; a net usually
encompasses a large city and the surrounding area. There are
usually many nets within each zone, each of which represents a
small geographical area within that zone.
Nodes are individual systems. Most nodes consist of bulletin
board systems, although a few nodes are devoted exclusively to
handling mail. If you wish to become a member of FidoNet and you
are running a BBS, this is probably where you will start.
Points are users on an individual system. Normally, points do
not run full-time systems, since they simply send and receive
mail through their "bossnodes" (the nodes where the points pick
up their mail). As the size of the network grows, points are
becoming increasingly popular. If you don't wish to run a full-
time system, this is probably where you'll start.
These four terms can be combined to give a "network address"
which identifies any one node in the network. The format of a
FidoNet address is as follows:
zone:net/node[.point]
For example, given a user in zone 1, in net 249, with a node
number of 106, and a point number of 2, that user's full address
would be '1:249/106.2'. The point number is optional, so both
1:249/106 and 1:249/106.0 refer to the bossnode of 1:249/106.2.
This mode of addressing is sometimes referred to as "4D" or four-
dimensional, since it includes the four basic elements of a
network address.
The Outside World
Like other electronic mail systems, it's possible to enter a
private message on a FidoNet system and have that message be
delivered to its final destination in a short period of time.
FidoNet systems "talk" with each other over telephone lines,
using one or more sophisticated handshaking protocols. To get a
message (known in this context as "NetMail") from point "A" to
point "B", the following sequence of events has to occur:
* The message is created. Most Fido-compatible software
packages can be used to generate a private message to a user on
another node. The destination address is entered, using the
standard 4D addressing scheme.
* The on-disk message is then converted to packet (or *.PKT)
form. If you are running BinkleyTerm, this will be performed by
Squish after a user logs off. If you are running FrontDoor or a
similar mailer type, this will be performed by the mailer itself
on startup, or while your mailer is connected to other systems.
There are four reasons for converting a message into a packet:
1) The packet structure is much more flexible than the local
message structure. All of the fields (such as the To:, From: and
Subject: fields) in a packet are variable length, whereas the
fields in stored messages are fixed-length.
2) Packets are the "compatibility layer". Since all systems
convert messages to the *.PKT format before sending them to
another system, there are few compatibility problems. This means
that systems can store their local message bases in different
formats, but still be able to exchange messages easily. In
addition, more than one message can be stored in a single packet.
Sometimes hundreds (or even thousands) of messages can be stored
in a single packet.
3) Messages in a packet can have a different address from the
packet itself. The packet itself has a destination (the system
where you'll be sending that packet directly to), but each
message has an individual destination address. This is useful,
for example, when a long-distance call is required to connect
with certain parts of the network. The message's final
destination always stays the same, but by sending the packet to
someone who is local to you (and then having that someone send it
to another local system, and so on), costs can be controlled
quite effectively. Since the interim destination of packet
doesn't need to be the same as the final destination of the
message, routing of messages via the lowest-cost route can be
performed.
4) Packets can be given a "flavour". A "flavour" (or a
behaviour characteristic) helps your system decide what to do
with an individual message. For example, the "hold" flavour
instructs your system to hold the message and wait for the
destination system to call and pick it up. Other flavours
include "crash" (send a message directly to the destination),
"direct" (same as crash), and "normal" (wait for later routing
commands).
Packets always have an extension of *.PKT. (Qualifier: if you
are running a BinkleyTerm system, they may have an extension of
*.HUT, *.OUT, *.CUT, or *.DUT on your local system, but Binkley
always changes them to *.PKT files before they are sent to
another system.)
* After the packet is created, it can be optionally archived
using a file compression utility. Compression is useful when
transferring large volumes of mail or sending to long- distance
sites, since compressing mail saves both time and money.
* The system which created the message then tries to call the
destination system. Obviously, if both systems are fairly busy,
this may take a while. Messages are sent back and forth between
systems through the use of mailers, also known as "front ends".
Mailers call out to deliver waiting mail, handle incoming
messages and files, and in general, supervise the entire file
transfer.
* After the two mailers connect (using one of several FidoNet
protocols), waiting mail and files are transferred between the
two systems.
* After the transfer completes, the receiving system then
tries to import the message. If the packet was compressed by the
sender, it will be decompressed. The *.PKT files will then be
imported (otherwise known as "tossed") into the local message
base, ready for the recipient to read.
Although transferring NetMail can involve much more than just
what is given above, this should give you a grasp on NetMail
fundamentals.
Is There an Echo In Here?
In the beginning, FidoNet consisted solely of nodes exchanging
NetMail. The only way to get a message from "here" to "there"
was to send a private NetMail message. However, a technology
called "EchoMail" was developed in late 1985; EchoMail is
analogous to a public message area or conference, but EchoMail
areas (sometimes known as "echoes") are shared among several
other systems.
EchoMail is organized into different groups of echoes, each with
a different topic. For example, the topics of FidoNet echoes
range from Maximus Support to deep-sea fishing and many more
special-interest groups. To facilitate topic-oriented EchoMail,
each echo must given a tag (or area name). This tag is used to
uniquely identify that EchoMail area when transferring messages
with other systems. (It doesn't matter what you call the echo on
YOUR system, as long as you are using the same tag as everyone
else.) Area tags are one word only, although they can include
periods and underscores. To start receiving an echo area, you
need to know the tag of that area. For example, the area tag for
the echo dealing with hardware and other technical issues is
"TECH".
EchoMail messages are normally public, and they are entered in a
message area just like a normal message. EchoMail messages also
look like normal, locally-entered messages, but with some special
control information at the bottom of each message.
After an EchoMail message is saved, an EchoMail utility (such as
Squish) is invoked to "scan" that message out to the rest of the
network. Unlike NetMail, EchoMail areas have an electronic
topology. Some echoes are very large, and as such, the cost to
directly send a message to each system which carried that echo
would be prohibitive. Instead, each system carrying that echo
only transfers EchoMail messages to neighbouring systems. (The
neighbour you receive an echo from is also known as your "feed".)
EchoMail messages get sent from the originating system to its
neighbours, and from those systems to their neighbours, and so
on. Despite this "hoppity-hop" method of transferring messages,
EchoMail is fairly quick; it can often take less than three days
for a message to travel from the USA to Australia and back.
Just like NetMail, echoes are sent to other systems in packets.
EchoMail messages are almost always compressed, since most of the
popular echoes have a daily throughput anywhere from 20 to 200
messages per day.
Copyright 1991 by Scott J. Dudley. All rights reserved.
Used with permission.
* * *